% !TEX root = main.tex

\section{Towards Heterogeneous Model-Driven Security}
\label{sec:heterogeneity}

\begin{figure}[b]
	\centering
	\includegraphics[width=\columnwidth]{./figures/trend}
	\caption{Evolution trend of Model-Driven Security}
	\label{fig:trend}
\end{figure}

\begin{figure}[t]
	\centering
	\includegraphics[width=0.6\columnwidth]{./figures/motivation}
	\caption{Example of integrating multiple security concerns}
	\label{fig:motivation}
\end{figure}

From \tab \ref{tab:comparison} and as discussed in \sect \ref{sec:criticism}, we are able to deduce the evolution trend of Model-Driven Security, illustrated in \fig \ref{fig:trend}.
The modeling language evolves from \uml profile to tailored \dsl, and the security concerns one MDS methodology may handle evolves from specific one to multiple ones.
However, such as \emph{ModelSec} evaluated in \sect \ref{sec:tailoreddsl}, even though a generic security requirement metamodel can cover several security concerns,
it still limits the modeling and analyzing capabilities due to the huge diversity among the security concerns.
A better solution is shown in the dashed rectangle in \fig \ref{fig:trend}: define several tailored \dsls and each
\dsl is dedicated to model a specific security concern. This, on one hand, holds satisfactory modeling and analyzing power of a tailored \dsl for a specific security concern,
and, on the other hand, may handle multiple security concerns under one framework/methodology, if the several security models expressed by different \dsls may be integrated
into one business model.

Figure \ref{fig:motivation} illustrates a simple example of such idea:
for a simple web-browsing system model, a \emph{UMLsec}-liked \dsl models an adversary machine which is used to simulates the threats on the communication channel 
(regarding information \emph{integrity/confidentiality}), while a \emph{secureUML}-liked \dsl models \rbac policies on the \emph{Server} side to manage \emph{access control}.

\begin{figure}[tb]
	\centering
	\includegraphics[width=\columnwidth]{./figures/Composition}
	\caption{Metamodel of simple ontology concept mappings}
	\label{fig:ontology}
\end{figure}

\begin{figure}[tb]
	\centering
	\includegraphics[width=0.6\columnwidth]{./figures/ontology_jointpoints}
	\caption{Example of partial equivalence defined as an ontology mapping}
	\label{fig:jointpoints}
\end{figure}

Regarding integration of various security models expressed by different tailored \dsls with one business model, \emph{ontology mapping} \cite{Kalfoglou:2003:OMS:975027.975028} 
might be a promising technique.
Figure \ref{fig:ontology} depicts a possible simple metamodel of ontology mapping. In this metamodel, an ontology is a super concept of two (partial) entities from different metamodels,
and it declares the relationship between these entities, \eg \emph{equivalent}.
A simple example is illustrated in \fig \ref{fig:jointpoints}.
The entity \emph{Resource} in metamodel \emph{A} is partially, excluding the property \emph{expiryTime}, equivalent to the entity \emph{View} in metamodel \emph{B},
as they are derived from a super concept \emph{Data} defined as an ontology mapping.
The ontology \emph{Data} is used to generate a \emph{Jointpoints} metamodel which will be used for future model weaving when two corresponding sub-concepts
\emph{Resource} and \emph{View} are encountered in the instance models of metamodel \emph{A} and metamodel \emph{B}.
Figure \ref{fig:conceptmappings} illustrates a more concrete example of ontology mappings defined to join a simple \emph{System} metamodel, which is defined as a \dsl
for modeling system business, and a simple \emph{AccessControl} metamodel, which is defined as a \dsl for modeling \rbac policies.
A mockup woven model is shown in \fig \ref{fig:woven}:  a simple web-browsing system business model is composed with an access control policy model
by corresponding equivalent concepts defined as ontology mappings in \fig \ref{fig:conceptmappings}.

\begin{figure}[tb]
	\centering
	\includegraphics[width=\columnwidth]{./figures/ConceptMappings}
	\caption{Example of ontology mappings between a simple System metamodel and a simple AccessControl metamodel}
	\label{fig:conceptmappings}
\end{figure}

\begin{figure}[tb]
	\centering
	\includegraphics[width=\columnwidth]{./figures/woven}
	\caption{Example of a possible woven model: a web-browsing system model composes with an access policy model by defined ontology mappings}
	\label{fig:woven}
\end{figure}

After successfully weaving models instantiated from different metamodels, another issue is \emph{property interpretation}.
Ontology mapping is used for interpreting corresponding concepts into a common concept for verification on final woven model.
For example, according to \fig \ref{fig:jointpoints}, if we want to verify a property: the \emph{value} of \emph{Resource} always equals the \emph{value} of \emph{View},
the final property checked by verification engine may be interpreted by substituting both \emph{Resource} and \emph{View} with their super concept \emph{Data} defined
in the ontology mapping, \ie:
\begin{equation*}
AG(ModelA.Data.value == ModelB.Data.value)
\end{equation*}
while \emph{ModelA} is an instance of metamodel \emph{A} and \emph{ModelB} is an instance of metamodel \emph{B}.

\begin{figure}[tb]
	\centering
	\includegraphics[width=\columnwidth]{./figures/heterogeneity_v02}
	\caption{Heterogeneous Y-Model}
	\label{fig:heterogeneity}
\end{figure}

Based on the above discussions, we propose the \emph{Heterogeneous Y-Model}, depicted in \fig \ref{fig:heterogeneity}, 
as a potential paradigm for future \mds development: both business and security
concerns should be modeled at the best level of abstraction, by limiting
accidental complexity due to the formalisms employed. The use of \dsls is the
primary artifact for properly capturing heterogeneity. In particular, security
concerns should not be integrated within the same metamodel, but should be
distributed among several \dsls so that each \dsl takes care of one specific concern.

%\fig \ref{fig:example} depicts an schematic overview of this approach, which
%fully benefit from their associated benefits \cite{B:Kleppe:2009}: visual model
%specification closely related to the domain notations; \dsls semantics and
%composition expressed with transformations, which enable automation and reuse,
%allowing engineers and experts to perform the associated analysis using the
%existing technology in the domain \cite{B:Kelly-Tolvanen:2008}.

%Although this approach addresses in a better fashion the crucial dimension of
%heterogeneity in business and security concerns, which is a major advantage for the design, it
%has several technical difficulties whose resolution should be carefully studied
%to fulfill its promises. We foresee two crucial challenges related to the fact
%that security concerns are spread over several models. First, it hinders its
%comprehension by the experts since they need to deal with several models at the
%same time, but this drawback is balanced by their narrowed focus. Second, it
%requires powerful composition operators for creating models that amalgamates all
%security aspects, which is crucial for later phases: whereas it becomes possible
%to analyze security properties independently, enforcement and code generation
%encompass all security aspects that need to be modeled before reaching platform
%code. Third, it complicates keeping all models synchronized: all security models
%somehow share some common information, which implies security models updates
%along time and according to business models evolutions; but more importantly,
%tracking back errors within the multiple security models after feedback is
%obtained from analysis occurring in subsequent layers becomes more complicated.



%The early \mds methodologies, \eg \emph{UMLsec} and \emph{secureUML}, apply \uml
%profiles to model system requirements. Regarding security concerns, these
%methodologies always concentrate on one specific aspect, \eg access control.
%Later researchers evolve \mds by developing tailored \dsls designed
%for modeling security properties at a generic security requirement metamodel
%level. The general security metamodel can be specialized by several extensions
%which form multiple security concern metamodels, \emph{c.f. ModelSec}.
%
%However, in our opinion, it is hard to develop a general \dsl to model multiple
%security concerns simultaneously due to their huge diversity. For better
%modeling and analysis capability, each security concern needs a specific
%tailored \dsl designed just for it, as shown in the dashed rectangle in \fig
%\ref{fig:trend} (a forecast to the future). We call this \emph{heterogeneity}
%and it comes from two sources: the business model has usually to mix several
%patterns and functionalities (\eg business rules expressing knowledge, but also
%its persistency); and the security concerns are also multiple in nature:
%authenticity, integrity, access control, delegation of responsibility, among
%others. If a development methodology does not reflect this very nature of such
%systems, then designing and deploying such systems needs too much effort and is
%too time and cost consuming.